A fundamental problem that a render service must address is how to arbitrate and schedule access to the render service. In practice, multiple render service clients compete for a limited amount of frame buffer real estate and graphics subsystem processing power. Solving this problem demands consideration of the nature of the service provided.
The problem of frame buffer real estate arbitration and scheduling of access to the graphics hardware is not unique to GLR. Window system services like X address this same problem, but the constraints are different. Typically, window systems arbitrate frame buffer access using overlapping windows. By clipping rendering to the visible regions of overlapping windows, a window system only requires that frame buffer state be maintained for exactly the number of pixels visible on the screen (no more, no less). Conveniently, pixel state for obscured window regions need not be maintained. More importantly, all visible window regions are always maintained so they can be displayed on a user's monitor.
In addition to frame buffer real estate arbitration, window systems must schedule graphics hardware access for window system clients. Typically, window systems accomplish this by simply interleaving rendering and other window system requests from multiple clients. To maintain the user's impression of simultaneous operation of various client applications, interleaving must happen at interactive rates.
The methods appropriate to a window system service for arbitrating frame buffer real estate and scheduling hardware access are not appropriate for a render service. Window system clients take continuous responsibility for updating newly visible regions of windows, and the overlapping is important to the user's ``desktop'' impression of access to multiple simultaneous graphical applications. And when scheduling access to the graphics hardware, interactivity is the key concern for window systems.
However, different priorities exist for render services in contrast to window systems. A render service must provide a client access to a rectangular frame buffer region of the requested size. This access should be provided independent of concurrent requests by other clients. The service must provide a guarantee of how frame buffer state is maintained. In practice, this means no overlapping of frame buffer rectangles requested by multiple clients. Also, issuing redraw events is inappropriate. Additionally, it is throughput, not interactivity, that is more important for a render service.
With a window system, the frame buffer
is continuously scanned out (displayed) to a computer screen;
this is fundamental to the purpose of a window system. In contrast to
a window system, a displayed frame buffer is not necessary for a
render service.
This also reflects something fundamental to the nature of a
render service. For a render service, rendering to the frame buffer
must be read back for the results of the rendering to be useful;
displaying of the frame buffer is not required.
Window systems virtualize frame buffer real estate spatially by overlapping windows and virtualize graphics hardware access temporally by fine-grain interleaving. For a render service however, spatial virtualization of screen real estate has limited applicability (tiling is possible, but not generally sufficient), but because a coherent viewable screen image is not necessary to a render service, temporal virtualization of frame buffer real estate (scheduling access to the frame buffer in time) is a viable technique. This scheduling of frame buffer real estate can be coarse-grain since interactivity is not a priority. The scheduling of access to the graphics hardware itself can also be done on the same coarse boundaries.
Conceptually, use of a render service is done as a series of renders, each followed by frame buffer read backs:
render, read back;
render, read back;
render, read back 
These render and read back pairs provides good boundaries for render service interactions by clients. Because the computer frame buffer state is read back, it is typically not necessary to retain frame buffer data for the client across these boundaries. This assertion is important because otherwise frame buffer state might need to be swapped in and out of the frame buffer (expensive!) when different render service clients share the same physical frame buffer state. For 3D scene rendering, the assertion is reasonable because 3D rendering of a scene typically does not rely on the previous scene. In the unusual situation when the assertion is not true, a client can restore the read back state from the previous rendering at the beginning of the next rendering.